This looks good to me. The only thing I've got in the back of my head is at least thinking about how this grows into a first class volume resource. Maybe it doesn't and thats OK.

This looks good to me. The only thing I've got in the back of my head is at least thinking about how this grows into a first class volume resource. Maybe it doesn't and thats OK.

My thought was in the future we could expand this to support something like the following by adding a new overload of WithVolume:

var pgdata = builder.AddContainerVolume("pgdata");
var pgdb = builder.AddPostgres("pg)
    .WithVolume(pgdata)
    .AddDatabase("db");

The manifest would then be updated to support writing out a container volume that refers to another resource via a '"resource"' property or similar.

cc @prom3theu5

Excellent thanks 😃
Definitely a nice feature

You say host bind mounts aren't included. What if for instance it's a Bind mount to an existing folder which contains required config, like Loki config / grafana data sources etc?

Wouldn't it be considered to be breaking if config which a service relies on at startup is missing?

For k8s I could bundle such directories as a container and use an init container to setup a pvc seeded with the data
For compose it could mount directly.

You say host bind mounts aren't included. What if for instance it's a Bind mount to an existing folder which contains required config, like Loki config / grafana data sources etc?

Yeah I think there's definitely ways to make it map, but it seems even Docker sees bind mounts as a legacy and encourages use of volumes instead now. We could of course just emit the bind mounts too and let the deployment tool decide what it wants to do, but ultimately bind mounts will require extra work in deployment to actually package up the hosting directory (if it exists) in some way and get it to the target.

Please log an issue to cover emitting bind mount details into the manifest so we can explore the idea further there.

Ok cheers - Will do 😄